home *** CD-ROM | disk | FTP | other *** search
/ Languguage OS 2 / Languguage OS II Version 10-94 (Knowledge Media)(1994).ISO / gnu / objcissu.lha / archiving next >
Internet Message Format  |  1993-03-01  |  4KB
  1. From shirley@gothamcity.jsc.nasa.gov Thu Sep 17 10:24:28 1992
  2. Return-Path: <shirley@gothamcity.jsc.nasa.gov>
  3. Received: from albert.gnu.ai.mit.edu by carrara.bos.marble.com (NX5.67c/Marble-3.0)
  4.     id AA04684; Thu, 17 Sep 92 10:24:21 -0400
  5. Received: from life.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
  6.     id <AA13193@albert.gnu.ai.mit.edu>; Thu, 17 Sep 92 09:59:35 -0400
  7. Received: from ames.arc.nasa.gov by life.ai.mit.edu (4.1/AI-4.10) id AA13127; Thu, 17 Sep 92 09:59:31 EDT
  8. Received: from gothamcity.jsc.nasa.gov by ames.arc.nasa.gov with SMTP id AA14595
  9.   (5.65c/IDA-1.4.4 for <gnu-objc@prep.ai.mit.edu>); Thu, 17 Sep 1992 06:59:28 -0700
  10. Received: from fdr.tech.lab by gothamcity.jsc.nasa.gov (4.1/SMI-4.1)
  11.     id AA26868; Thu, 17 Sep 92 08:58:43 CDT
  12. Date: Thu, 17 Sep 92 08:58:43 CDT
  13. From: shirley@gothamcity.jsc.nasa.gov (Bill Shirley [CSC])
  14. Message-Id: <9209171358.AA26868@gothamcity.jsc.nasa.gov>
  15. To: gnu-objc@prep.ai.mit.edu
  16. Subject: Re: Automatic input/output, persistence
  17.  
  18.  
  19.  I tried to send this easlier, but it bounced at the source.  I hope
  20. I'm not repeating something you already got:
  21.  
  22. ]] From shirley Fri Sep 11 13:47:30 1992
  23.  
  24.  
  25. |> From: gdb0@lehigh.edu (GLENN BLANK)
  26.  
  27. I don't understand most of this, I may need more explaining to.
  28.  
  29. |> A key difference between the NeXT and StepStone foundation class
  30. |> libraries is the latter supports a much more convenient scheme
  31. |> for storing objects to and reading them back from files.
  32.  
  33. |> The NeXT version, as I understand it (I don't have a NeXT; I have
  34. |> a Sun running Stepstone's version), only supports what I would call
  35. |> "semi-automatic" input/output--that is, the implementor of each subclass
  36. |> must implement methods to archive objects of this subclass.  The
  37.  
  38. On NeXTs, the implementor must archive the instance variables
  39. (that he wants archived)
  40.  
  41. |> Stepstone library does not require any new implementation at all.  If
  42. |> your object is a subclass of Stepstone's Object, it automatically
  43. |> inherits Object's hooks automatic input/output--providing you
  44. |> explicitly link in the relevant code.  
  45.  
  46. What does this *mean*?
  47.    "automatically... providing..."?
  48.  
  49. What relevant code?
  50.  
  51. |> Semi-automatic input/output is about all C++ libraries can do:
  52. |> since C++ does not support metaclass information at run-time.
  53. |> Automatic input/output is one of the very nice features of Smalltalk,
  54. |> which Objective-C can imitate, because it does support metaclasses,
  55. |> and so can know how to allocate instances of some class when it
  56. |> reads one from a file.
  57.  
  58. What happens if I have modified the Class in the interim?
  59. (This is a problem that all implementations have to deal with,
  60.  I am interested in how Stepstone does (or you (pl) would) in this case)
  61.  
  62. |> Needless to say, automatic input/output
  63. |> can save a lot of work, especially in continually evolving
  64. |> applications like mine.
  65.  
  66. By continually evolving, do you mean class implementations are changing?
  67.  
  68. |> I'd sure like to see support for it in the 
  69. |> GNU version, rather than settle for the NeXT interface.
  70.  
  71. I'll wait to vote until I understand it :-)
  72.  
  73. |> May I point out that automatic input/output also opens the door
  74. |> for object persistence.  This need not imply a full blown OODB,
  75. |> with query capabilities, etc.
  76.  
  77. What does "object persistence" mean?  I'll have to plead ignorant
  78. on much DB theory.
  79.  
  80. |> The StepStone implementation stores 
  81. |> one whole object per file
  82.  
  83. That does sound like a limitation
  84.  
  85. |>                 --the object can be arbitrarily complex,
  86. |> e.g., the filer will handle vanilla C instance variables, 
  87. |> chase object ids, yet avoid duplicating objects to which there
  88. |> is more than one pointer.  A more flexible design might allow one 
  89. |> to store/access many objects per file.  
  90.  
  91. like NIB files.
  92.  
  93. What if an object creates a large amount of instance variables that it
  94. doesn't NEED to archive.  (It could create this extra data for algorithmic
  95. efficiency, for example).
  96.  
  97. (A string object may keep the number of characters,
  98. the size of the storage it allocated, the number of words, whether the
  99. characters are all numeric, alphabetic,..., but you would only NEED to
  100. archive the actual sequence of characters, the other information can
  101. be computed after the string is unarchived.)
  102.  
  103.  -Bill S.
  104.  
  105.